-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor the SettingsTab to be a pane #16172
Conversation
…rminal-panes-2023
…/fhl/scratchpad-pane
## Summary of the Pull Request Builds upon #16170. This PR simply adds a singly type of non-terminal pane - a "scratchpad pane". This is literally just a single text box, in a pane. It's on the `{ "command": "experimental.openScratchpad" }` action. ## References and Relevant Issues See: #997 ## Detailed Description of the Pull Request / Additional comments I also put it behind velocity so it won't even go into preview while this bakes. This is really just here to demonstrate that this works, and is viable. The next PR is much more interesting. ## Validation Steps Performed Screenshot below. ## other PRs * #16170 * #16171 <-- you are here * #16172
This is in dev/migrie/f/sui-panes...dev/migrie/b/remove-terminaltab That's ready to go here, but there's also still another two PRs stacked on top of here. Let's merge those in too, before the noisy rename & move |
// Do nothing. We'll later be updated manually by | ||
// UpdateTerminalSettings, which we need for profile and | ||
// focused/unfocused settings. | ||
assert(false); // If you hit this, you done goofed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: i'd prefer a more specific and actionable message than "you done goofed"
@@ -383,7 +390,7 @@ namespace winrt::TerminalApp::implementation | |||
return RS_(L"MultiplePanes"); | |||
} | |||
const auto activeContent = GetActiveContent(); | |||
return activeContent ? activeContent.Title() : L""; | |||
return activeContent ? activeContent.Title() : winrt::hstring{ L"" }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit
return activeContent ? activeContent.Title() : winrt::hstring{ L"" }; | |
return activeContent ? activeContent.Title() : winrt::hstring{}; |
These are equivalent, but now that you have to specify the type explicitly we may as well switch to the nullary constructor
// HORRIBLE | ||
// | ||
// Workaround till we know how we actually want to handle state | ||
// restoring other kinda of panes. If this is a settings tab, just |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// restoring other kinda of panes. If this is a settings tab, just | |
// restoring other kinds of panes. If this is a settings tab, just |
|
||
namespace TerminalApp | ||
{ | ||
[default_interface] runtimeclass TerminalPaneContent : IPaneContent, ISnappable | ||
{ | ||
Microsoft.Terminal.Control.TermControl GetTermControl(); | ||
|
||
void UpdateSettings(const Microsoft.Terminal.Settings.Model.TerminalSettingsCreateResult settings, | ||
const Microsoft.Terminal.Settings.Model.Profile profile); | ||
void UpdateTerminalSettings(TerminalSettingsCache cache); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From an "offline" (lol) discussion:
It may make sense here to construct TerminalPaneContent
with a shared reference to the TerminalSettingsCache
and then let UpdateSettings()
create the cached objects lazily. That way we avoid the extra API function and try_as
tests.
We can do this in a follow-up PR.
…splitPane`, `newTab` (#16914) This changes `NewTabArgs`, `SplitPaneArgs`, and `NewWindowArgs` to accept a `INewContentArgs`, rather than just a `NewTerminalArgs`. This allows a couple things: * Users can open arbitrary types of panes with the existing `splitPane`, `newWindow` actions, just by passing `"type": "scartchpad"` (for example). This is a lot more flexible than re-defining different `"openScratchpad"`, `"openTasksPane"`, etc, etc actions for every kind of pane. * This allows us to use the existing machinery of session restore to also restore non-terminal panes. The `type` property was added to `newTab`, `splitPane`, `newWindow`. When omitted, we still just treat the json as a blob of NewTerminalArgs. There's not actually any other kinds of `INewContentArgs` in this PR (other than the placeholder `GenericContentArgs`). In [`dev/migrie/fhl/md-pane`](dev/migrie/f/tasks-pane...dev/migrie/fhl/md-pane), I have a type of pane that would LOVE to add some args here. So that's forward-thinking. There's really just two stealth types of pane for now: `settings`, and `scratchpad`. Those I DON'T have as constants or anything in this PR. They probably should be? Though, I suspect around the time of the tasks & MD panes, I'll come up with whatever structure I actually want them to take. ### future considerations here * In the future, this should allow extensions to say "I know how to host `foo` content", for 3p content. * The `wt` CLI args were not yet updated to also accept `--type` yet. There's no reason we couldn't easily do that. * I considered adding `ICanHasCommandline` to allow arbitrary content to generate a `wt` commandline-serializable string. Punted on that for now. ## other PRs * #16170 * #16171 * #16172 * #16895 * #16914 <-- you are here Closes #17014
... technically. We still won't let it actually be a pane, but now it acts like one. It's hosted in a
SettingsPaneContent
. There's no moreSettingsTab
. It totally can be in a pane (but don't?)Validation Steps Performed
Related PRs
Refs #997
Closes #8452